出处：https://blog.csdn.net/weixin_43215482/article/details/87932734

1、service层出现的契机：mvc框架由model，view，controller组成，执行流程一般是：在controller访问model获取数据，通过view渲染页面。mvc模式是web开发中的基础模式，采用的是分层设计，各层之间职责分明。然而事与愿违，当我们日积月累的基于mvc模式开发之后，会逐渐的感受到层与层之间存在粘连和职责模棱两可的地方，这就是service层出现的重要原因。

2、mvc模式在实践过程中，主要面临下面几个难受的问题：

在C层直接实现业务逻辑，这将导致：

-不同的controller之间，无法共享通用的业务逻辑，比如：折扣计算，反作弊判定，这必然是不合理的。

-业务逻辑升级，需直接在原代码上做修改兼容，导致controller代码不断膨胀复杂。

-远程服务协议或者调用方式升级，需要找到所有controller里的调用点，逐一修改。

-DAO发生替换（比如从oracle迁移mysql），需要找到所有controller里的调用点，逐一修改。

在M层（DAO+model或者ActiveRecord，下面以model泛指）里实现业务逻辑，这将导致：

-model承担了过多的业务逻辑，导致业务逻辑升级需要修改model，然而model的职责并不是业务，这是很矛盾的。

-调用1个model中的业务代码没有问题，但是遇到跨表事务又该由哪个model管理呢？

-业务逻辑实现在model中，如果model发生变更，那么里面写的业务逻辑也得粘贴复制到新的model中，这就是耦合的代价。

问题的本质是：业务逻辑粘连了C层和M层，应该从C层&M层解耦出来，成为独立的Service层。由此，在C层可以灵活的替换Service保持高度的简洁，而M层保持职责单一仅仅为Service提供数据，Service层则实现所有复杂的业务逻辑与通用的业务逻辑。

3、Service层的职责：      根据上面的分析，Service夹在C层和M层中间，从逻辑上大致划分为3大类：

      在实践中，应该会很自然的用到这三类Service，在了解了这些概念之后再进行代码设计，就不会对Service的职责产生困惑了，自然也对MVC有了新的认识。

4、抽象：

Controller里调用"controller侧的Service"直接完成业务处理，意味着Controller依赖了具体是哪个Service类。

Service里调用"DAO/AR"实现数据库的访问，意味着Service依赖了具体是拿个"DAO/AR"类。

Service里调用Service，意味着Service依赖了具体是拿个Service类。

为了解除这种耦合，在Web领域一般采用的都是IOC依赖注入来实现"依赖反转"，JAVA和PHP都可以基于反射实现这个能力，各个mvc框架都有相似的实现。

其它参考：

https://www.cnblogs.com/youmingkuang/p/11963404.html

https://www.cnblogs.com/laowenBlog/p/12937429.html